1장. HLS의 정의와 등장 배경

1.1 스트리밍의 본질과 초기 방식

스트리밍이란 데이터를 모두 다운로드하지 않고 전달받으면서 동시에 재생하는 방식이다.

초기 스트리밍 기술은 이 개념을 구현하기 위해 “지속적인 연결“을 기반으로 설계되었다.

대표적인 프로토콜은 다음과 같다.

이 방식의 핵심 구조는 이렇게 정리된다.

클라이언트와 서버가 연결을 유지한 상태에서 데이터를 끊임없이 전달한다

실시간성 측면에서는 효과적이었지만 인터넷 환경 전체를 고려하면 여러 한계를 가지고 있었다.

1.2 기존 스트리밍 구조의 한계

연결 기반 스트리밍은 다음과 같은 구조적 문제를 가진다.

1) 연결 상태에 대한 강한 의존성

스트리밍이 진행되는 동안 연결이 유지되어야 하므로 네트워크 변화에 매우 민감하다.

• 네트워크 전환 (Wi-Fi → LTE)
• 일시적인 패킷 손실
• 연결 지연

이런 상황이 발생하면 스트리밍 품질이 즉시 영향을 받는다.

2) 재연결 비용과 복구 문제

연결이 끊어지면 단순히 이어서 재생되지 않는다.

복구를 위해 다음 과정이 필요하다.

• 재연결 (handshake)
• 스트림 위치 동기화
• 버퍼 재구성

이 과정은 사용자에게 “영상이 멈추고 한참 뒤에 다시 시작되는 경험“으로 이어진다.

3) 모바일 환경에서의 비효율

연결을 계속 유지하는 구조는 다음과 같은 비용을 만든다.

• 네트워크 인터페이스 지속 활성화
• CPU 사용 증가
• 배터리 소모 증가

특히 모바일 환경에서는 이 문제가 치명적이다.

4) 웹 인프라와의 비호환성

기존 스트리밍은 HTTP 기반이 아니다. 따라서 다음 문제가 발생한다.

• CDN 캐싱 활용이 어렵다
• 웹 트래픽과 분리된 별도 인프라가 필요하다
• 방화벽 통과가 까다롭다

이는 대규모 서비스 확장에 큰 제약이 된다.

1.3 Apple의 문제 정의

이러한 한계를 해결하기 위해 Apple은 근본적인 질문을 던졌다.

“스트리밍은 반드시 연결을 유지해야 하는가?”

이 질문은 단순한 개선이 아니라 스트리밍의 전제를 뒤집는 접근이었다.

1.4 HLS의 핵심 아이디어

Apple이 제시한 해법은 이렇다.

스트리밍을 ’연결 기반’이 아니라 ’요청 기반’으로 바꾸자

기존 방식이 하나의 연결 위에서 데이터를 흘려보냈다면

HLS는 데이터를 여러 단위로 나누고 필요할 때마다 요청해서 가져오는 방식이다.

이 변화는 단순한 구현 차이가 아니라 시스템의 성격 자체를 바꾼다.

연결 기반 vs 요청 기반

이 구조를 한 문장으로 정리하면 이렇다.

HLS는 스트리밍을 “데이터 흐름“이 아니라 “리소스 요청“으로 재정의한 기술이다

1.5 HTTP 기반 설계의 의미

HLS는 HTTP/HTTPS 위에서 동작한다.

이 선택은 단순한 구현 편의가 아니라 전략적 결정이다.

1) 웹 인프라와의 완전한 통합

• 기존 웹 서버 사용 가능
• CDN 캐싱 활용 가능
• 별도 프로토콜 불필요

스트리밍이 웹 트래픽의 일부가 된다.

2) Stateless 구조

각 요청은 독립적으로 처리된다.

• 연결 유지 불필요
• 실패 시 다음 요청으로 복구 가능
• 서버 자원 효율적 사용

네트워크 환경 변화에 강한 구조가 된다.

3) 네트워크 및 방화벽 친화성

HLS는 일반 웹 요청과 동일하게 동작한다.

• 포트 80 / 443 사용
• HTTP GET 요청 기반

대부분의 네트워크 환경에서 자연스럽게 허용된다.

여기서 중요한 표현 하나를 기억하자.

HLS는 방화벽을 “우회하는 기술“이 아니라 애초에 차단되지 않는 방식으로 설계된 기술이다

1.6 시장과 기술의 교차점

HLS는 기술적 해결책이면서 동시에 플랫폼 전략의 일부였다.

당시 스트리밍 시장은 Adobe의 Flash 기반 기술이 지배하고 있었다.

Flash 기반 구조의 특징:

• RTMP 중심
• 플러그인 의존
• 데스크탑 환경 중심

Apple의 전략

Apple은 다음 방향을 선택했다.

• iPhone에서 Flash 미지원 선언 (2007)
• HTML5 기반 웹 생태계 채택
• HTTP 기반 스트리밍 도입 (HLS, 2009)

이 선택은 단순한 기술 교체가 아니라 스트리밍의 권력 구조를 바꾸는 결정이었다.

결과적으로 이렇게 정리된다.

스트리밍은 플러그인 기술에서 웹 표준 기술로 전환되었다

1.7 스트리밍 패러다임의 전환

HLS의 등장 이후 스트리밍은 다음과 같이 변화했다.

Before

• 연결 중심
• 특수 프로토콜
• 환경 의존적

After

• 요청 중심
• HTTP 기반
• 웹과 완전히 통합

이 변화의 핵심은 다음 한 문장으로 요약된다.

스트리밍은 더 이상 특수한 기술이 아니라, 웹 기술의 일부가 되었다

1.8 HLS의 설계 목표와 구조적 한계

HLS는 특정 목표를 기반으로 설계되었다.

설계 목표

• 안정성
• 확장성
• 네트워크 호환성

그 결과 발생하는 한계

이 구조는 자연스럽게 다음 특성을 만든다.

• 데이터가 준비된 이후 전달됨
• 요청 단위로 처리됨
• 클라이언트가 polling으로 갱신을 확인함

결과:

구조적으로 지연(Latency)이 발생한다

이 부분은 매우 중요하다.

HLS는 초저지연을 위해 만들어진 기술이 아니다. 안정성과 확장성을 우선한 기술이다.

이 지연이 왜 발생하는지는 5장에서 본격적으로 다룬다.

1.9 HLS vs MPEG-DASH: 같은 시기, 다른 길

HLS가 등장한 비슷한 시기에 또 다른 HTTP 기반 스트리밍이 표준화됐다.

MPEG-DASH다.

둘은 자주 비교되지만, 철학과 구조가 다르다.

같은 점

• HTTP 위에서 동작
• 영상을 segment로 나눠 전송
• 적응형 비트레이트(ABR) 지원

다른 점

왜 두 기술이 공존하는가

DASH는 기술적으로 더 유연하고 표준 친화적이다.

하지만 iOS/tvOS에서 HLS만 네이티브로 재생되기 때문에 글로벌 서비스는 HLS를 선택할 수밖에 없다.

결국 많은 서비스는 둘 다 만든다.

• HLS → Apple 생태계용
• DASH → Android / Web / Smart TV용

이 분기를 줄이기 위해 등장한 것이 7장에서 다룰 CMAF다.

1장 한 줄 정리

HLS는 스트리밍을 “연결“에서 “요청“으로 재정의했고, 그 대가로 지연을 감수했다.